1. Technical Field of the Invention
The present invention relates in general to the field of telephony accounting and, in particular, to a method for use by telephone system operators to ensure that pre-paid subscribers can pay for simultaneous telephone calls.
2. Description of Related Art
Currently, most mobile telephone subscribers pay for their mobile calls after they receive a monthly bill from their service provider (commonly referred to as "post-paid" accounting). This process of monthly accounting requires a substantial amount of administrative support in order for the service provider to collect the call data, calculate the costs for the calls, send bills to the subscribers, etc. Use of these post-paid accounting systems typically requires the service providers to check into their subscribers' creditability, and ultimately trust the subscribers to pay their bills on time.
The concept of pre-paid accounting has been recently introduced into the mobile telephony market. Generally, the following two mobile pre-paid accounting approaches have been introduced: (1) the Intelligent Network (IN) approach; and (2) the Call Detail Record (CDR) approach.
An Intelligent Network is a mobile network architecture that relocates specific services and databases from switches to one or more network control and decision points. Such a network architecture contains Service Switching Points (SSPs) or switches with bearer and basic service control capabilities, Service Control Points (SCPs) or elements with advanced service control capabilities, and a Service Management System (SMS) that controls the deployment of services and associated service data. A more detailed description of mobile IN architectures is given in "Cellular Radio Systems" by D. M. Balston and R. C. V. Macario, published by Artech House, Inc. (1993).
Using IN technology for pre-paid mobile telephony accounting, a subscription for each pre-paid customer is stored in a subscriber database in a system's IN node. Each subscription field in the IN node contains certain information such as, for example, the number of charging units (to be used for the payment of a call), dates (e.g., when the charging units or subscription will expire, when announcements are to be played, etc.), and other subscriber related information (e.g., tariff class, lists of barred and allowed numbers, and other restrictions and information about subscribers). This subscriber information can be stored in the IN's Service Control Function (SCF), an external database (e.g., a Service Data Function or SDF), or both. The charging units can be any unit value, as long as the unit is fully convertible between monetary value, time value, and meter pulses (described below).
For mobile systems using the CDR approach for pre-paid accounting purposes, the call data records are collected similar to those in conventional billing systems. However, a difference between the post-paid and pre-paid CDR approaches is that the pre-paid CDR approach maintains a dedicated pre-paid account in a database for each mobile subscriber. When a call has been made and a resulting CDR is being processed by the system, the cost of the call is calculated and deducted from the amount in the subscriber's account. If the account reaches zero (or a negative value) the pre-paid system orders the mobile network to bar the subscriber from making additional calls. A dedicated service number to an Interactive Voice Response (IVR) subsystem can be associated with such an accounting system, which a service subscriber can call and request the account's balance (e.g., a bank-by-phone machine).
A CDR accounting system can handle parallel calls (e.g., during multi-party calls, call forwarding, or call holding), because the cost of these calls can be calculated after the calls' completion. However, because of the delay in the delivery of the CDR, there is an obvious risk that the subscribers will run up charges for more calls than their account will cover.
The basic problem that has to be solved is to determine how to control the value of a pre-paid account while calls are ongoing. In an IN solution, pre-paid calls are routed in the network to the Service Switching Function (SSF). The SSF then signals the SCF to inform the SCF about the call. In this signalling message, the SSF sends, for example, the A-number (calling party number), B-number (called party number), location information, and other relevant information to the SCF. The SCF, which recognizes the A-number (B-number) as belonging to an IN subscriber, determines whether the calling party (called party) subscriber is allowed to make (receive) that call (considering the pre-paid account's value). This determination can be made in the SCF after retrieving the charging unit information, and expiration and subscription dates, etc.
If the SCF determines that the call can be allowed, the SCF sends the number of remaining charging units in the account to the SSF to be used for charging of the call, and the call is connected. When the called party answers the call, the SSF starts counting meter pulses (with each meter pulse equal to one charging unit).
If the call is disconnected before all of the charging units in the account are used up, the number of charging units used for that call is transferred back to the SCF, which deducts that amount from the amount in the account. On the other hand, if the call's duration is long enough so that the number of meter pulses counted in the SSF equals the number of charging units that were transferred from the SCF, then the call is disconnected and the account value is set to zero.
A big problem with the existing pre-paid approaches is that when a call is to be set up, all of the value of the account is made available to cover the cost of that call. During the call, this value is depleted continuously, but there is no practical way to view this depletion in real-time. Using an existing IN technology approach, the node where the pre-paid account is stored will not know how many charging units have been used, until the call has been completed and the number to be deducted from the account has been transferred from the SSF. Consequently, during the call, the value of the account reflects a value which is larger than the actual remaining value. If another call is set up at this time, a value larger than the actual value will be made available for this call.
For example, if a pre-paid subscriber sets up a call, the number of charging units remaining in the subscriber's account (e.g., 100) will be copied to the SSF. The SSF sets up the call and starts the process of counting meter pulses. If, however, during this ongoing call, the subscriber desires to set up another call (e.g., a conference call), the system's multi-party service function is used to set up the call. Since the exact value in the account is not known outside the process in the SSF associated with the original call, the only value known is the original value (100) which is still stored in the SCF. This original value is copied a second time to the SSF to start a new process in the SSF associated with the new call. Unfortunately, unless conference calls are not allowed, this recopying of the original value can be repeated as many times as there are connections (x) to be made in the conference call. Therefore, every connection (x) made in the conference call can deplete the original (100) charging units. In this example, the pre-paid subscriber will thus be able to call for x*100 charging units, although the pre-paid account only had 100 charging units to start with.
The same problem occurs if a pre-paid subscriber uses call forwarding, since the multiple call processes involved can be simultaneously depleting the original charging units in the account. For example, with the service called "Call Forwarding on Busy" (CFB) this double-charging can occur each time the subscriber is involved in a call and another party makes an incoming call. Also, if the pre-paid subscriber uses Call Forwarding Unconditional (CFU), Call Forwarding on Not Reachable (CFNRc), or Call Forwarding on No Reply (CFNRy), the same double-charging problem can arise if there is an ongoing forwarded call and the subscriber makes an outgoing call. The same problem can occur if the pre-paid subscriber uses the Call Hold function, makes two outgoing calls, and then toggles between them.
Another situation where parallel transactions and double-charging can occur, is when a recurring subscription fee or other type of payment is made to an external system (e.g., billing system, bank, credit card service provider, etc.) and deducted from the pre-paid account. If a call is ongoing while the payment is being made, the system will not know whether the amount to be deducted will be covered or not, until the ongoing call is completed.